Linkage of relationship and transaction data

ABSTRACT

A system and method for providing an individual with information on the actual healthcare utilization of other members of that individual&#39;s social network, the method including de-identifying or encrypting individually identifiable social network data associated with a first user, de-identifying or encrypting individually identifiable healthcare transaction data associated with the first user, and linking the de-identified social network data and the de-identified healthcare transaction data.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/987,197, the disclosure of which is incorporated herein byreference.

BACKGROUND Field of the Invention

The present invention relates to data to support decision-making, morespecifically data to support healthcare decision-making.

Background of the Invention

According to the Pew Internet Life survey, 72 percent of adult internetusers say they looked online for health information within the pastyear. Of these, 77 percent of online health seekers say they began at asearch engine such as Google, Bing, or Yahoo. Another 13 percent saythey began at a site that specializes in health information, like WebMD.Just 2 percent say they started their research at a more general sitelike Wikipedia and an additional 1 percent say they started at a socialnetwork site like Facebook.

Most online health information-seeking activity to date has focused ondisease and treatment, with over half of all users engaging in lookingfor information relevant to disease and diagnosis. Notably, despite theavailability of a number of sites that facilitate provider reviews,health care reviews have not caught on among general consumers. While 8in 10 internet users say they have researched a product or serviceonline, less than one in five internet users have consulted onlinereviews and rankings of health care service providers and treatments.Similarly, when it comes to writing reviews of general-interest items,37 percent of internet users say they have rated a product, service, orperson online and 32 percent have posted a comment or review onlineabout product they bought or service they received. People are much lesslikely to post a review of a treatment, hospital, or clinician. Between3-4 percent of internet users have done so.

Compared to many other consumer-directed areas, healthcarerecommendations, particularly around healthcare provider choice, stillremains an area that is dominated by the word-of-mouth opinions offriends and family as well as the recommendation and referral of thepatient's current healthcare provider as opposed to utilizing unverifiedand uncurated healthcare provider reviews online. According to theCenter for Studying Health System Change, over 50 percent of primarycare choices are aided by word-of-mouth from friends or relatives. Whilethat number drops to approximately 20 percent for specialists, it can besurmised that the reduction is partially due to the increased role ofthe healthcare provider in recommending referrals to the patient as wellas the difficulty of the patient finding relevant information for morespecialized needs within a narrow offline friends and family network.Additionally, with the proliferation of health plan options and with thegrowing need for consumers to select healthcare providers from everchanging lists of in-network and out-of-network providers, the need forconsumers to identify new healthcare providers will only continue toincrease.

Traditional reasons patients search for new healthcare providers includesuspecting a new condition or problem, seeking a second opinion, moving,changing insurance, dissatisfaction with their current doctor, costs, orneeding a certain procedure. As noted, today this is usuallyaccomplished by word-of-mouth from family and friends or byrecommendation by healthcare providers. While a number of sites such asHealthgrades, Vitals, WebMD, Yelp, Practice Fusion and Zocdoc providesome sort of doctor search functionality, most sites rely on acombination of quasi-factual directory information (provider specialty,payers accepted, education, location, hours) and patient reviews, andnone of these sites leverage any sort of trusted referral methodology.Unfortunately, the lack of scale, comprehensiveness, and currency ofpatient reviews combined with the lack of curation means that mostindividuals do not use or trust these reviews today. For many othersubject areas such as finding a restaurant or buying consumerelectronics, the nature of those doing the reviewing may not be highlyrelevant to those reading the reviews. In healthcare, however, mostpatients and caregivers have a more complex view of who to trust indetermining which healthcare providers to use and the quality of thehealthcare providers that is not being met by current models.

According to a 2014 Associated Press-NORC Center for Public AffairsResearch study, family and friends are the most trusted source ofquality ratings about doctors, with over 60% of Americans saying theywould very much or completely trust quality ratings of doctors or otherhealth care providers they receive from friends or family members,versus roughly half saying they would trust quality ratings they receivefrom their regular doctor or other individual health care provider.Beyond those two sources, however, Americans overwhelmingly lack trustin other sources of quality ratings of health care providers. Currentprovider ratings websites rank near the bottom, with only 10% sayingthey trust the quality ratings they receive from these sources.

Therefore, there is a need for an improved system and method of storing,linking, querying, and reporting healthcare data.

SUMMARY

In order to overcome these and other drawbacks of the related art, thereis provided a system and method for providing an individual withinformation on the actual healthcare utilization of other members ofthat individual's social network. The system and method may provide asource of referrals by linking the social graph or social relationshipsof an individual generated through their participation in an onlinesocial network to healthcare providers and the attributes of thosehealthcare providers that are treating members of that individual'ssocial network. The system and method may allow the individual to seeall the healthcare providers that his or her social network already usein a way that protects the identities and healthcare data privacy of theunique individuals in the group. The system and method may also be usedto allow an individual to see the experience in his or her socialnetwork with other healthcare utilization, for example with particularhealthcare facilities, procedures done, and other medical relatedactivities.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments will be set forth with reference to the drawings,in which:

FIG. 1 is a prospective view illustrating a process for dataaggregation, de-identification, and linkage according to an exemplaryembodiment of the present invention; and

FIG. 2 is a prospective view illustrating a process for generating aresulting physician dataset according to an exemplary embodiment of thepresent invention.

FIG. 3 is an overview of a system according to an exemplary embodimentof the present invention.

FIG. 4A illustrates a graphical user interface according to an exemplaryembodiment of the present invention.

FIG. 4B illustrates a graphical user interface according to anotherexemplary embodiment of the present invention.

FIG. 5 illustrates a graphical user interface according to anotherexemplary embodiment of the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Exemplary embodiments of the present invention will be set forth indetail with reference to the accompanying drawings, in which likereference numerals refer to like elements throughout.

Referring now to the invention in more detail, FIG. 1 is a prospectiveview illustrating a process 100 for data aggregation, de-identification,and linkage according to an exemplary embodiment of the presentinvention. The process 100 may include a series of components to enablethe de-identification, linkage, querying and reporting of social networkdata linked to healthcare data. Referring to FIG. 1, the process 100 mayinclude a data store 110 containing a source of social networkrelationship data, a data store 120 containing a source of healthcaretransactional data, methods 112 and 122 for de-identifying or encryptingpersonally identifiable information in each data store, a method forlinking data from the two data stores 110 and 120 in a de-identifieddata store 130, and the ability to query the data 140 regarding datarelated to a specific individual and receive a response 150.

The social network data 110 includes social network data records thatare produced by a social network site and includes individuallyidentifiable data fields such as but not limited to name, date of birth,gender, geographic location or other personally identifiable data thatshows the identities of each member of the social network as well as thelinks or associations between each individual in the social network andall other members of his or her social network that is created by theprocess of individuals associating with each other online through thesocial network.

The healthcare transaction data 120 includes individual-level healthcareclinical or transactional data that may be generated from one or moresources of healthcare information such as but not limited to pharmacies,health insurance claims processors or clearinghouses, insurers, orprovider organizations, and includes some or all of the same data fieldsas noted in the prior step above such as but not limited to name, dateof birth, gender, geographic location or other personally identifiabledata that shows the identities of each individual in the data as well astheir associated healthcare transactions that identify the treatingphysician such as physician office visits or dispensed prescriptions.

There is shown a process 112 for using a hash function or encryptionalgorithm or other method to de-identify the data records and replacethe identifiable data fields noted in the step above for the datarecords of all of the individuals who are the subject of the socialnetwork data and producing a file that contains each unique individualkey tied to the unique keys of other individuals in their social networkas contained in the social network data store. In a further iteration,this step may also contain a separate individual customer or memberidentifier generated by the social network data provider. There are anumber of published and commercially available methods that permit suchde-identification and deterministic or probabilistic linkage to occur.Examples of such de-identification and matching processes are reportedin U.S. Pat. Nos. 6,732,113 and 6,397,224, or made availablecommercially by companies such as Management Science Associates Inc.(http://msa.com/life-sciences/solutions/de-identification-engine) andUniversal Patient Key, Inc. (http://universalpatientkey.com/). Furtherexamples exist in the literature, such as Durham E., Xue Y.,Kantarcioglu M., and Malin B., Private Medical Record Linkage withApproximate Matching, American Medical Informatics Association 2010Symposium Proceedings, 182-186; and Schnell R., Bachteler T., and ReiherJ., Privacy-preserving record linkage using Bloom filters, BMC MedicalInformatics and Decision Making 2009, 9:41.

There is shown the same process 122 as in the prior step for using a thesame hash function or encryption algorithm noted in the step above toreplace the identifiable data fields above for the data records of allthe individuals who are the subject of the healthcare data producing afile that contains a unique individual key for each person that iscontained in the healthcare data store tied to each of their healthcareclinical or transactional data.

As the same hash function or encryption algorithm 112 and 122 is used inboth of the prior two steps, the unique individual key that is generatedby the hash function or algorithm for each individual that is common toboth data sets will be the same (or similar enough that the system isable to match common individual keys by deterministic or probabilisticmatching). The system links data for each individual in the socialnetwork data store and data for the same individual in the healthcaredata store. For example, a name and date of birth from the social mediadata record may generate a key after being hashed or encrypted that maybe matched either deterministically or probabilistically to the samename and date of birth being hashed or encrypted in the healthcare data.

There is shown a process for assembling the social network data and thehealthcare data for all individuals in both data stores into one or morerelated data stores 130 that may be linked at the individual level bythe unique key generated in the prior three steps. As noted, there are anumber of alternate methods for linking on various series of informationthat rely on both the exact matching of the keys (deterministic) ormatching of the keys based on degrees of similarity (probabilistic).

FIG. 2 is a prospective view illustrating a process 200 for generating adataset of healthcare providers according to an exemplary embodiment ofthe present invention.

The process 200 may include a process 210 for an individual accessing awebsite or mobile application using their social network login or otherinformation to identify them and associate them with their socialnetwork data.

A user may be granted access to the social media profile and the usermay be associated with other users in one or more social networks inprocess 212.

As seen in FIG. 2, there is shown a process for the user submitting thequery 140 via the website or mobile application against the data store130 assembled in the prior steps in order to provide a combined seriesof records of all healthcare services utilization for their user-definedsocial network. As one mechanism of increasing the specificity of thequery 140, the query 140 can be limited by the user based on selectedcriteria 240 about the healthcare providers that provided the healthcareservices in the data, such as (but not limited to) the medical specialty242 of a treating physician or other healthcare provider, the hospital,practice group or other professional affiliations 244 of a physician orother healthcare provider, the payers 246 that the healthcare provideraccepts, and the geographic location 248 of the healthcare provider.That query would be run against the combined data store 130 thatincludes the social network linkages as well as the healthcare data, andwould provide an assembled dataset in response to the aforementionedquery 140 that uses a set of unique keys from specific individualsgenerated from the social network data tied to the user and who relateto each other via the connections within the social network data. Suchkeys may be linked to the actual associated healthcare data for thoseindividuals, such as physician office visits, and from the healthcaredata would include treating physician names or identifiers or otherhealthcare related information such as procedures performed or diagnosesfor each healthcare service in the data store for each of these keys.

In the example shown in FIG. 2, the user performing the query 140 isassigned an individual user ID 252. The user's social network(s)includes linked individuals 234 a, 234 b, and 234 c. The de-identifieddata store 130 indicates that individual 234 a is linked to healthcareproviders 236 a, 236 b, and 236 c and individual 234 b is linked tohealthcare provider 236 d. The de-identified data store 130 alsoindicates that individual 364 c is linked to healthcare provider 236 aand 236 b, respectively). Finally, individual 234 c is linked tohealthcare provider 236 e.

The process 200 may also include a process 150 for summarizing the datato report on the combined listing of the data produced in the priorstep. Such summarization may include but not be limited to rank order byfrequency of occurrence or other measures.

The process 200 may also include an optional step 240 to suppress anyquery results that have frequency or other descriptive characteristicsthat may create a risk of the underlying source healthcare data beingre-identified by the user as to the actual identities of the individualswho received such services.

The process 200 may also include a process 252 for displaying thecombined data produced in the prior step either through a web browser ormobile or desktop computer application so that a individual can see alisting of all healthcare providers that have treated other individualswho are linked to that individual through their social network, withoutseeing the specific identities of the linked individuals that associateto each healthcare provider, as the linkage has been made without theneed to expose identifiable data.

This process 200 can also be applied to other healthcare utilizationdata generated from the healthcare data sources above besides healthcareprovider names, in order to allow an individual user to see thecompilation of other healthcare usage of the individual's socialnetwork, such as hospital names, procedures performed, or drugs used.

The advantages of the present invention include, without limitation, theability to leverage an individual's social network to link to existinglarge-scale healthcare datasets in a privacy-protecting fashion as wellas the ability to do this on a broad scale, unlike other online reviewswhich are based on user-generated reviews from users not related to theindividual seeking recommendations, and as such are not as trustworthyand require significant time to produce any adequate volume of reviewsabout a specific healthcare provider.

FIG. 3 is an overview of the system 300 according to an exemplaryembodiment of the present invention.

The system 300 may include one or more servers 310 and one or moredatabases 320 connected to a plurality of remote computer systems 340,such as one or more personal systems 350 and one or more mobile computersystems 360, via a network 330.

The one or more servers 310 may include an internal storage device 312and a processor 314. The one or more servers 310 may be any suitablecomputing device including, for example, an application server and a webserver which hosts websites accessible by the remote computer systems340. The one or more databases 320 may be internal to the server 310, inwhich case they may be stored on the internal storage device 312, or itmay be external to the server 312, in which case it may be stored on anexternal non-transitory computer-readable storage medium, such as anexternal hard disk array or solid-state memory. The one or moredatabases 320 may be stored on a single device or multiple devices. Thenetwork 330 may include any combination of the internet, cellularnetworks, wide area networks (WAN), local area networks (LAN), etc.Communication via the network 330 may be realized by wired and/orwireless connections. A remote computer system 340 may be any suitableelectronic device configured to send and/or receive data via the network330. A remote computer system 340 may be, for example, anetwork-connected computing device such as a personal computer, anotebook computer, a smartphone, a personal digital assistant (PDA), atablet, a notebook computer, a portable weather detector, a globalpositioning satellite (GPS) receiver, network-connected vehicle, etc.The one or more personal computer systems 350 may include an internalstorage device 352, a processor 354, output devices 356 and inputdevices 358. The one or more mobile computer systems 360 may include aninternal storage device 362, a processor 364, output devices 366 andinput devices 368. The internal storage devices 312, 352, and/or 362 maybe non-transitory computer-readable storage mediums, such as hard disksor solid-state memory, for storing software instructions that, whenexecuted by a processor 314, 354, or 364, carry out relevant portions ofthe features described herein. The processors 314, 354, and/or 364 mayinclude a central processing unit (CPU), a graphics processing unit(GPU), etc. The processors 314, 354, and 364 may be realized as a singlesemiconductor chip or more than one chip. An output device 356 and/or366 may include a display, speakers, external ports, etc. A display maybe any suitable device configured to output visible light, such as aliquid crystal display (LCD), a light emitting polymer display (LPD), alight emitting diode (LED), an organic light emitting diode (OLED), etc.The input devices 358 and/or 368 may include keyboards, mice,trackballs, still or video cameras, touchpads, etc. A touchpad may beoverlaid or integrated with a display to form a touch-sensitive displayor touchscreen.

The system 300 may be used by a single user or multiple userssimultaneously. The system 300 may be realized by software instructionsaccessible to and executed by the server 310 and/or downloaded andexecuted by the remote computing system 340. As used herein, the term“users” may refer to individuals, organizations, or entities.

The social network data 110, healthcare transaction data 120, andde-identified data 130 may be stored in one or more non-transitorycomputer readable storage mediums (for example, the database(s) 320).Each data store 110, 120, and 130 may include one or more databases.Alternatively, the data stores 110, 120, and/or 130 may be stored in thesame database. Each of the process steps (for example, the process 100,the process 200, etc.) may be stored in a non-transitory computerreadable storage medium for execution by one or more processors.

FIG. 4A illustrates a graphical user interface output to a remotecomputer system 340 according to an exemplary embodiment of the presentinvention.

A user may request access to one or more social networks as described instep 210 above. In the example shown, the user may separately requestaccess social networks, such as FACEBOOK, GOOGLE PLUS, and LINKED IN.Alternatively, the user interface may enable a user to request access tomultiple social media accounts with a single login. The login may beprovided by one of the social media services or a third party service.The user interface may include an optional feature 412 that enables auser to search healthcare providers associated with the user's socialnetwork(s) (e.g., the user's friends or direct connections) orassociated with the user's extended social network(s) (e.g., friends ofthe user's friends or individuals that are connected to the user my morethan one degree).

As described above, the user may perform a query 140 (or filter queryresults 150) by specifying a location 248. The query 140 may include ageographic location (e.g., a municipality or other geographic area).Alternatively, the query may include all locations within a radius of ageographic location or within a radius of the location of the remotecomputer 340. The location of the remote computer 340 may be determinedby GPS, cellular network triangulation, IP address, etc. In the exampleshown in FIG. 4A, the query 140 includes all medical practices andhospitals within 5 miles of the 19146 zip code.

In the embodiment shown in FIG. 4A, the query results 150 are output tomap view 400 a. The query results 150 may include, for example,information regarding each healthcare provider (e.g., the type ofhealthcare provider) and/or the popularity of the healthcare providerwithin the user's social network(s) or extended social network(s) (e.g.,the number of contacts within the user's social network(s) or extendedsocial network(s) with healthcare records that indicate an associationwith each healthcare provider).

FIG. 4B illustrates a graphical user interface output to a remotecomputer system 340 according to another exemplary embodiment of thepresent invention. The user may request access to one or more socialnetworks as described in step 210 above. The user may perform a query140 (or filter query results 150) by specifying a location 248. The usermay also specify the type of healthcare provider, healthcare providerspecialty, payers accepted (e.g., insurance networks), physician gender,physician board certification(s), language(s), hospital or practiceaffiliation, diseases treated, procedures performed, etc. In the exampleshown in FIG. 4B, the query 140 includes all primary care physicians 5miles of the remote computer 340 location.

FIG. 5 illustrates a graphical user interface output to a remotecomputer system 340 according to another exemplary embodiment of thepresent invention.

A user may request access to one or more social networks as described instep 210 above. As described above, the user may perform a query 140 andspecify a location 248. In the example shown in FIG. 5, the queryresults 150 are shown in a list view, which may be sorted by popularitywithin the user's social network(s), name, address (e.g. distance fromlocation 248), rating, etc. The popularity within the user's socialnetwork(s) may be determined based on the number of individuals in theuser's social network(s) (e.g., friends) with healthcare records thatindicate use of the healthcare provider, the number of individuals inthe user's extended social network(s) (e.g., friends of friends) thathave used the healthcare provider, the number of visits to thehealthcare provider from individuals in the user's social network(s) orextended social network(s), etc. The system 300 may also allow users torate healthcare providers. The ratings may be de-identified or encryptedas described above to enable a user to provide an anonymous rating toindividuals within his or her social network(s).

As used herein, the term “healthcare provider” may include doctors,medical professionals, hospitals, medical practices, diagnostic centers,imaging centers, medical suppliers, medical services, urgent careclinics, retail clinics, pharmacies, etc. As used herein the term“social network” may include any computer platform that indicatesrelationships between individuals, such as people who share interests,activities, backgrounds, and/or real-life connections.

While the foregoing written description of the invention enables one ofordinary skill to make and use what is considered presently to be thebest mode thereof, those of ordinary skill will understand andappreciate the existence of variations, combinations, and equivalents ofthe specific embodiment, method, and examples herein. The inventionshould therefore not be limited by the above described embodiment,method, and examples, but by all embodiments and methods within thescope and spirit of the invention.

1.-10. (canceled)
 11. A method, comprising: receiving individuallyidentifiable relationship data associated with a first user and a seconduser, the individually identifiable relationship data associated withthe second user including a link or association with the first user;receiving individually identifiable transaction data associated with thefirst user; de-identifying or encrypting the individually identifiablerelationship data associated with the first user to form de-identifiedrelationship data associated with the first user by using a hashfunction or encryption algorithm to generate a first key and replacingdata identifying the first user with the first key; de-identifying orencrypting the individually identifiable transaction data associatedwith the first user to form de-identified transaction data associatedwith the first user by using the hash function or encryption algorithmto generate a second key and replacing data identifying the first userwith the second key; identifying de-identified relationship andtransaction data associated with the first user by making adetermination that the first key is identical or similar to the secondkey; and outputting the de-identified transaction data associated withthe first user to the second user in response to a determination thatthe de-identified relationship data associated with the second userincludes a link or association with the first user.
 12. The method ofclaim 11, wherein the data identifying the first user includes a name ordate of birth of the first user.
 13. The method of claim 11, wherein thede-identified transaction data associated with the first user is outputto the second user in response to a query initiated by the second user.14. The method of claim 11, wherein: the hash function or encryptionalgorithm generates the first key by hashing or encrypting the dataidentifying the first user in the individually identifiable relationshipdata associated with the first user; the hash function or encryptionalgorithm generates the second key by hashing or encrypting the dataidentifying the first user in the individually identifiable transactiondata associated with the first user.
 15. The method of claim 11, whereinthe determination that the first key is identical or similar to thesecond key is a deterministic or probabilistic determination.
 16. Themethod of claim 11, wherein the individually identifiable relationshipdata associated with the first user comprises individually identifiablesocial network data associated with the first user.
 17. The method ofclaim 11, wherein the individually identifiable transaction dataassociated with the first user comprises individually identifiablehealthcare transaction data associated with the first user orindividually identifiable clinical data associated with the first user.18. The method of claim 11, wherein the de-identified transaction dataoutput to the second user identifies a physician of the first user. 19.The method of claim 11, wherein the de-identified transaction dataoutput to the second user identifies a healthcare facility utilized bythe first user, a treatment received by the first user, or a medicationdistributed to the first user.
 20. The method of claim 11, whereinreceiving individually identifiable relationship data associated withthe second user includes a link or association with a third user, themethod further comprising: receiving individually identifiabletransaction data associated with the third user; de-identifying orencrypting the individually identifiable transaction data associatedwith the third user; summarizing the de-identified transaction dataassociated with the first user and the de-identified transaction dataassociated with the third user; and outputting, to the second user, thesummary of the de-identified transaction data associated with the firstuser and the de-identified transaction data associated with the thirduser.
 21. A system, comprising: a relationship database for storing:individually identifiable relationship data associated with a firstuser; and individually identifiable relationship data associated with asecond user that includes a link or association with the first user; atransaction database for storing individually identifiable transactiondata associated with the first user; and a processor configured to:de-identify or encrypt the individually identifiable relationship dataassociated with the first user to form de-identified relationship dataassociated with the first user by using a hash function or encryptionalgorithm to generate a first key and replacing the data identifying thefirst user with the first key; de-identify or encrypt the individuallyidentifiable transaction data associated with the first user to formde-identified transaction data associated with the first user by usingthe hash function or encryption algorithm to generate a second key andreplacing the data identifying the first user with the second key;identify de-identified relationship and transaction data associated withthe first user by making a determination that the first key is identicalor similar to the second key; and output the de-identified transactiondata associated with the first user to the second user in response to adetermination that de-identified relationship data associated with thesecond user includes a link or association with the first user.
 22. Thesystem of claim 21, wherein the data identifying the first user includesa name or date of birth of the first user.
 23. The system of claim 21,wherein the processor outputs the de-identified transaction dataassociated with the first user to the second user in response to a queryinitiated by the second user.
 24. The system of claim 21, wherein: thehash function or encryption algorithm generates the first key by hashingor encrypting the data identifying the first user in the individuallyidentifiable relationship data associated with the first user; the hashfunction or encryption algorithm generates the second key by hashing orencrypting the data identifying the first user in the individuallyidentifiable transaction data associated with the first user.
 25. Thesystem of claim 21, wherein the processor determines that the first keyis identical or similar to the second key by making a deterministic orprobabilistic determination.
 26. The system of claim 21, wherein theindividually identifiable relationship data associated with the firstuser comprises individually identifiable social network data associatedwith the first user.
 27. The system of claim 21, wherein theindividually identifiable transaction data associated with the firstuser comprises individually identifiable healthcare transaction dataassociated with the first user or individually identifiable clinicaldata associated with the first user.
 28. The system of claim 21, whereinthe de-identified transaction data output to the second user identifiesa physician of the first user.
 29. The system of claim 21, wherein thede-identified transaction data output to the second user identifies ahealthcare facility utilized by the first user, a treatment received bythe first user, or a medication distributed to the first user.
 30. Thesystem of claim 21, wherein: the individually identifiable relationshipdata associated with the second user includes a link or association witha third user; the transaction database stores individually identifiabletransaction data associated with the third user; and the processor isconfigured to: de-identify or encrypt the individually identifiabletransaction data associated with the third user; summarize thede-identified transaction data associated with the first user and thede-identified transaction data associated with the third user; andoutput, to the second user, the summary of the de-identified transactiondata associated with the first user and the de-identified transactiondata associated with the third user.